fix(kafka): strip kafka config from Consumer.consume() args#432
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesKafka Consumer Option Filtering
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
AbstractKafkaConsumer.init() forwards the entire stored options — including the connection-level kafka config — into @platformatic/kafka's Consumer.consume(). Inside consume(), the MessagesStream constructor runs structuredClone(otherOptions) on whatever it doesn't explicitly destructure. Anything function-valued reachable from the kafka config crashes that clone with DOMException [DataCloneError], taking down consumer init.
The most common trigger is AWS MSK IAM authentication, which uses SASL/OAUTHBEARER with an async token provider:
Production stack trace:
The same class of bug would hit any function-valued field passed through SASL/OAUTHBEARER providers (Confluent Cloud OIDC, etc.).
Fix
Exclude kafka from the spread that builds consumeOptions in init():
kafka is connection-level config — it belongs on the Consumer constructor (where it's already spread separately), not on consume(). Stripping it makes the consume args structuredClone-safe regardless of what's inside the user's connection config.
Tests
Two regression tests in PermissionConsumer.spec.ts that spy on Consumer.prototype.consume:
Verified both fail on the unfixed code — the second test reproduces the exact production stack trace — and pass with the fix applied.
Summary by CodeRabbit
Bug Fixes
Tests